auto merge of #779 : alexcrichton/cargo/update-deps, r=alexcrichton

Update deps with fail => panic

Also fix a few test's assertion messages

fail -> panic

auto merge of #772 : mattyhall/cargo/master, r=alexcrichton

Fixes #762. I'm not sure if I've used the correct style here. Apologies if it is and/or if the way I've fixed this is wrong!

auto merge of #702 : tomassedovic/cargo/run-examples, r=alexcrichton

This lets users run any executable from the `examples` or `bin` directories by
passing its name with `--example` or `--bin` flag.

If neither is specified, we fall back to the old behaviour (running the only bin
target in the project, failing if there are more).

Closes #538

auto merge of #768 : alexcrichton/cargo/ssl-fixes, r=brson

The second commit message has the details, and these are the relevant external commits:

* https://github.com/alexcrichton/openssl-static-sys/commit/2e1c50a7f35ef52ce38dbd405a175b6dccc0ebad
* https://github.com/alexcrichton/curl-rust/commit/1098e4dd3b89b168b412dfeaba033e41796ea794

Fix compat with the current rust master

Update curl-rust to handle SSL config for linuxes

Right now the cargo built on the snapshot bot isn't able to talk to the registry
due to failing to validate the SSL certificate. This is likely due to the
certificate path being hardcoded to something that's compatible with CentOS
(which isn't what I'm running locally).

I've modified curl-rust to use openssl-static-sys to probe the system for where
certificates are located and inform handles by default about the found
locations. This is the same strategy that git2-rs uses to inform openssl about
where the certificates are located.

Make help command accept -h and --help

Add `--name` to `cargo test` and `cargo bench`

You can now run a single test/bench file by passing its name to `cargo
test` or `cargo bench`.

Register new snapshots and update the lockfile format

Add `--name` and `--example` to cargo run

This lets us compile and run examples using `cargo run --example NAME`.
Selecting the other binary targets is now done using the `--name` flag.

`cargo run` falls back to the old behaviour (running the only bin target
in the project, failing if there are more) in neither `--name` nor
`--example` are present.

Closes #538

auto merge of #769 : tomaka/cargo/delete-design, r=alexcrichton

Remove .vimrc, MANIFEST.md, and the DESIGN directory

auto merge of #767 : alexcrichton/cargo/issue-637, r=wycats

Each dependency itself already has the precise source listed, and we're
guaranteed that for each (source, name) pair that there is exactly one
dependency, so there is always a way to rebuild the precise dependency graph
after the fact by looking up the (source, name) pair in the hash map.

This should help with some of the readability concerns in #637 because the git
SHA that a source is locked to is now only mentioned once in a lockfile.

This commit does preserve, however, the mention of the version in each
dependency line which will likely never go away. This means that for
registry-based packages will still run into the same lockfile merge conflict
troubles, there will just be more readable versions than git hashes.

It should also be noted that this will alter all currently generated lockfiles
as any dependencies mentioned will lose the hashes mentioned afterwards. This
will likely cause somewhat of a transitionary pain as this version of cargo
propagates throughout.

Don't encode precise in lockfile dep pointers

Each dependency itself already has the precise source listed, and we're
guaranteed that for each (source, name) pair that there is exactly one
dependency, so there is always a way to rebuild the precise dependency graph
after the fact by looking up the (source, name) pair in the hash map.

This should help with some of the readability concerns in #637 because the git
SHA that a source is locked to is now only mentioned once in a lockfile.

This commit does preserve, however, the mention of the version in each
dependency line which will likely never go away. This means that for
registry-based packages will still run into the same lockfile merge conflict
troubles, there will just be more readable versions than git hashes.

It should also be noted that this will alter all currently generated lockfiles
as any dependencies mentioned will lose the hashes mentioned afterwards. This
will likely cause somewhat of a transitionary pain as this version of cargo
propagates throughout.

auto merge of #765 : steveklabnik/cargo/fix_warnings, r=alexcrichton

auto merge of #758 : alexcrichton/cargo/issue-751, r=brson

This ends up killing two birds with one stone! The rationale behind this is that
the example and bin namespaces are not the same, and we don't mix metadata into
either filename, so the outputs need to be in different locations.

Closes #193
Closes #751

auto merge of #757 : alexcrichton/cargo/issue-743, r=brson

Closes #743

auto merge of #734 : alexcrichton/cargo/issue-728, r=brson

Previously only the local package was erroneously compiled with optimizations.

Closes #728

auto merge of #725 : alexcrichton/cargo/registry-fixes, r=brson

This PR contains a laundry list of improvements when using the registry as a source, and should be one of the last steps necessary for whipping cargo into shape to using the registry. Some of the highlights include:

* All APIs have been updated to the registry's current interface
* Lockfiles are now respected with registry sources
  * Conservatively updating dependencies should work
  * The network shouldn't be touched unless absolutely necessary
  * Lockfiles actually keep versions locked when using a newer registry with more versions
* A new standalone lib was added for interoperating with the registry (HTTP-request-wise)
* Packages are now verified before being published to the registry (this can be opted out of)
* `cargo upload` was renamed to `cargo publish`

The commit series is intended to be individually reviewable and each commit should compile and pass all tests independently (but still needs to be applied in order).

auto merge of #766 : alexcrichton/cargo/fix-test-state, r=alexcrichton

Ensure that a system `rm -rf target` will continue to work across test runs.

Propagate configuration parser errors

Closes #743

Build examples into `target/examples`

This ends up killing two birds with one stone! The rationale behind this is that
the example and bin namespaces are not the same, and we don't mix metadata into
either filename, so the outputs need to be in different locations.

Closes #193
Closes #751

Don't leave behind corrupt directories

Ensure that a system `rm -rf target` will continue to work across test runs.

Document the new manifest keys

Avoid updating the registry too frequently

This logic is based off the precision of the registry source's id as well as the
dependencies being passed in. More info can be found in the comments.

Remove some unused imports

Add a cache to the registry source

This should help avoid hitting disk wherever possible and will also be leveraged
in just a second!

Respect yanks in the registry

In general the semantics of a yank are that the code itself is not removed from
the registry, but rather packages are no longer allowed to depend on the
version. A yank is normally done to remove broken code or perhaps secrets, but
actually deleting code means that all packages depending on the yanked version
all of a sudden break. For these reasons a yank does not actually delete code,
but only flags the version as yanked in the index.

Yanked packages are therefore able to be depended upon if a lockfile points at a
yanked version, but are not allowed to become new dependencies of packages.

Implementation-wise, the following changes were made:

* SourceIds originating from a lockfile for registries will have a precise
  version listed (just a generic string "locked")
* Dependencies which use precise source ids are allowed to read yanked versions
* Dependencies without a precise source id are not allowed to use yanked
  versions

When using a lockfile (or a previous instance of resolve), all operations will
rewrite dependencies to have the precise source ids where applicable, meaning
the locked versions have access to yanked versions, but the unlocked versions do
not.

Fix a flaky test relying on nondeterminsm

When updating a source with multiple packages, the registry will lazily discover
both the precise and imprecise versions of the source at some point. Previously
the source would be updated depending on which was discovered first, but this
commit adds logic to understand that if an imprecise version is discovered after
a precise version then the imprecise version should be favored (because it will
always trigger an update).

This needs to understand, however, that if `cargo update --precise` is used that
those sources should not be updated again, so the sources treated in
`add_sources` are considered "special" in the sense that they're locked and will
not be updated again.

Make SourceKind private

This is a bit of an implementation detail of the `SourceId` and we should be
able to get away without exposing it.

Integrate the lockfile and registry-based deps

This commit radically changes the approach of how lockfiles are handled in the
package registry and how resolve interacts with it. Previously "using a
lockfile" entailed just adding all of the precise sources to the registry and
relying on them not being updated to remain locked. This strategy does not work
out well for the registry, however, as one source can provide many many packages
and it may need to be updated for other reasons.

This new strategy is to rewrite instances of `Summary` in an on-demand fashion
to mention locked versions and sources wherever possible. This will ensure that
any relevant `Dependency` will end up having an exact version requirement as
well as a precise source to originate from (if possible). This rewriting is
performed in a few locations:

1. The top-level package has its dependencies rewritten to their precise
   variants if the dependency still matches the precise variant. This covers the
   case where a dependency was updated the the lockfile now needs to be updated.
2. Any `Summary` returned from the package registry which matches a locked
   `PackageId` will unconditionally have all of its dependencies rewritten to
   their precise variants. This is done because any previously locked package
   must remain locked during resolution.
3. Any `Summary` which points at a package which was not previously locked still
   has its dependencies modified to point at any matching locked package. This
   is done to ensure that updates are as conservative as possible.

There are still two outstanding problems with lockfiles and the registry which
this commit does not attempt to solve:

* Yanked versions are not respected
* The registry is still unconditionally updated on all compiles.

Restructure resolve/lockfile ops

Move functionality from cargo_fetch and cargo_generate_lockfile into dedicated
lockfile/resolve modules. The plan is to expand the resolve module significantly
to deal with the lockfile that's loaded.

Make it easier to map dependencies in a summary

This will hopefully become useful in the upcoming changes to resolve for
lockfiles with the registry.

Rewrite registry tests for easier mocking and such

Don't de-dup added sources

We have a hash map on the side and a method that already aborts re-adding a
source if it was already added.

Don't seed Registry with known source ids

In the normal case this isn't necessary due to the Registry dynamically
discovering sources when dependencies are queried for. Consequently there's no
need to register all these sources ahead-of-time, and it reduces the cognitive
load when thinking about sources and updates.

Remove the hokey add_lockfile_sources

This method shouldn't be necessary as it should be possible to simply add all
sources known in the lockfile to a package registry, and
core::{resolve, registry} should take care of weeding them out if necessary.

In the process of doing so, this actually ends up fixing a problem with
rewriting a dependency to a new one which shares transitive deps. Previously all
the transitive deps were updated, but now the transitive deps remain locked at
where they were previously locked.

Update how cargo talks to the registry

This commit includes a laundry list of updates and tweaks to reflect the current
API of the registry:

* `registry.host` has been renamed to `registry.index`
* New top-level manifest keys are now accepted:
  * `homepage` - url
  * `documentation` - url
  * `repository` - url
  * `description` - a markdown-less blurb
  * `license` - string (verified by the registry on upload)
  * `keywords` - string array
  * `readme` - string pointing at a file
* Authors are now uploaded to the registry
* The upload format to the registry has changed to a body json payload
* Unpacking tarballs respects the executable bit for scripts and such.
* Downloading now follows redirects to go to S3.
* The download URL for a package has changed slightly.
* Verify path dependencies have a version listed when being uploaded
* Rename `upload` to `publish`
* Rename `ops::cargo_upload` to `ops::registry`
* Add a new `registry` package for interoperating with the registry
* Add the ability to modify owners via `cargo owner`
* Add a `readme` key to the manifest, and upload its contents to the registry.
* Add the ability to yank crates and their versions
* When packaging a library, verify that it builds from the packaged source by
  unpacking the tarball and simulate running `cargo build` inside of it.

fix two warnings

auto merge of #718 : alexcrichton/cargo/issue-715, r=brson

We won't make much progress reporting the error back up the chain, so we may as
well carry on!

Closes #715

auto merge of #761 : kali/cargo/patch-1, r=alexcrichton

Two typos

auto merge of #755 : pwoolcoc/cargo/fix-664, r=alexcrichton

cargo new: Don't create a git repo in subdirectory

Running `cargo new` to create a subpackage shouldn't create another
git repository if one exists in a parent directory.

Closes #664

auto merge of #750 : alexcrichton/cargo/no-more-travis-32, r=alexcrichton

This has been broken for quite awhile now on 32-bit linux due to what looks like
libcurl going awry. This can be reactivated later, but consistently green travis
builds are more important right now.

Additionally, we already have coverage on the buildbots for 32-bit flavors of
architectures.

auto merge of #754 : blaenk/cargo/whitespace, r=alexcrichton

I missed this when I changed the values to the defaults! It simply lines up the comment with the one above it.

line up the comments

auto merge of #752 : alexcrichton/cargo/typos, r=alexcrichton

Fix some copy-paste errors in CLI help

Stop testing 32-bit on travis

This has been broken for quite awhile now on 32-bit linux due to what looks like
libcurl going awry. This can be reactivated later, but consistently green travis
builds are more important right now.

Additionally, we already have coverage on the buildbots for 32-bit flavors of
architectures.

auto merge of #747 : kballard/cargo/manifest_typo_fix, r=alexcrichton

Fix typo in src/doc/manifest.md

auto merge of #710 : alexcrichton/cargo/metadata, r=wycats

In terms of future compatibility, Cargo may wish to add more information to
lockfiles in the future. For example, the minimum required Rust version may one
day be encoded into a lockfile.

One of the major goals of a lockfile is for it to rarely change, and when it
does change the diffs should be minimal. In terms of adding more information to
the lockfile in the future, this presents a problem for older Cargo clients:

1. Cargo 2.0 adds a minimum required version of rust under the metadata.rustc
   key of the lockfile.
2. Cargo 1.0 is then used to update the `foo` dependency in the lockfile. When
   regenerating the lockfile, Cargo 1.0 discards the metadata inserted by Cargo
   2.0.

In order to future-proof ourselves in allowing new metadata in the future, Cargo
is growing support now for transporting an opaque payload of metadata from one
version of a lockfile to a new versions. This should solve the problem presented
above.

This metadata section is designed to be safely ignored by older Cargo versions
(may just have some surprising behavior), while still allowing newer versions of
Cargo to process the data. For example Cargo 2.0 would gracefully fail on an
out-of-date rustc, while Cargo 1.0 may just present an obscure error message.

r? @wycats

Add a metadata section to the lockfile

In terms of future compatibility, Cargo may wish to add more information to
lockfiles in the future. For example, the minimum required Rust version may one
day be encoded into a lockfile.

One of the major goals of a lockfile is for it to rarely change, and when it
does change the diffs should be minimal. In terms of adding more information to
the lockfile in the future, this presents a problem for older Cargo clients:

1. Cargo 2.0 adds a minimum required version of rust under the metadata.rustc
   key of the lockfile.
2. Cargo 1.0 is then used to update the `foo` dependency in the lockfile. When
   regenerating the lockfile, Cargo 1.0 discards the metadata inserted by Cargo
   2.0.

In order to future-proof ourselves in allowing new metadata in the future, Cargo
is growing support now for transporting an opaque payload of metadata from one
version of a lockfile to a new versions. This should solve the problem presented
above.

This metadata section is designed to be safely ignored by older Cargo versions
(may just have some surprising behavior), while still allowing newer versions of
Cargo to process the data. For example Cargo 2.0 would gracefully fail on an
out-of-date rustc, while Cargo 1.0 may just present an obscure error message.

auto merge of #737 : gentoo90/cargo/bash-comp, r=alexcrichton

Requested in #531

auto merge of #717 : alexcrichton/cargo/souped-up-resolve, r=wycats

This series of commits is rebased on top of https://github.com/rust-lang/cargo/pull/712 to avoid conflicts, and it adds the ability to solve version constraints as part of the resolution process. This is a critical step forward in bringing the registry online as it makes it possible for cargo to figure out what to do in the face of many uploaded versions of a package to the registry.

r? @wycats

Make to_url public for rustc

Avoid visiting deps too often in resolve

If we're activating an already-active version of a dependency, then there's no
need to actually recurse into it. Instead, we can skip it if we're not enabling
any extra features in it to avoid extraneous recursion.

source changes

Continue reducing clone costs

Share the `visited` hash set among all contexts, just be sure to maintain it
across failures. Also put all Summary structures into an `Rc` as they're cloned
quite frequently.

Make SourceId cheap to clone

Like PackageId, these are cloned quite often, so this moves them into an Arc to
make them cheap to clone. This also removes the public fields in favor of
accessors.

Make PackageId cheap to clone

These are cloned a massive number of times during resolution, so let's make them
much cheaper to clone with an Arc. This uses Arc instead of Rc because the
fiddly bits in job_queue have a PackageId cross task boundaries for parallelism.

Implement resolution of version requirements

This commit extends the support in cargo's resolver to start resolving packages
with multiple versions as well as package requirements. This is a crucial step
forward when impelmenting the cargo registry as multiple versions will be
uploaded to the registry quite quickly!

This implements a fairly naive solution which should at least help cargo get out
the gates initially. This impelments a depth-first-search of the pacakage
dependency graph with a few sorting heuristics along the way to help out
resolution as it goes along.

Resolution errors will likely improve over time, but this commit does make an
effort to try to get some good error messages right off the bat.

Split out encoding from `core::resolver` to a submodule

Same exported hierarchy, just some internal orgainzational changes.

Update semver to have `^` be the default operator

Create bash_completion.d directory

Add bashcomp to Makefile.in

Bash completion initial support

Compile deps with optimizations for benches

Previously only the local package was erroneously compiled with optimizations.

Closes #728

auto merge of #732 : alexcrichton/cargo/update, r=alexcrichton

Also merge some other PRs while I'm at it

Update dependencies to unbreak the build

Merge remote-tracking branch 'tomaka/add-docs' into update

Merge commit 'jdeseno/remove-deprecated' into update

Add general doccomments

Replace usage of `get_ref`

auto merge of #722 : blaenk/cargo/rpath-docs, r=alexcrichton

The `rpath` option was added (awesome!) but not documented.

use rpath defaults

document rpath option in manifest

auto merge of #721 : EduardoBautista/cargo/update-docs-url, r=alexcrichton

Update docs url

auto merge of #720 : alexcrichton/cargo/no-more-plugins, r=brson

It's looking more likely like plugins will not make it into the stable channel
of Rust, so this commits removes Cargo's personal dependence on the two
plugin-based pieces of functionality it was using:

1. Uses of the `regex!` macro now go through `Regex::new`.
2. Uses of the `docopt!` macro now go through `deriving(Decodable)` instead.

auto merge of #711 : alexcrichton/cargo/issue-708, r=brson

I can't quite remember why this ifdef is present to silently run `make` as a
normal user, and it doesn't seem to work if `make install` is run while as root,
so I'm just removing it and requiring that `make` is run before `make install`
unconditionally.

Closes #708

Remove dependence on various plugins

It's looking more likely like plugins will not make it into the stable channel
of Rust, so this commits removes Cargo's personal dependence on the two
plugin-based pieces of functionality it was using:

1. Uses of the `regex!` macro now go through `Regex::new`.
2. Uses of the `docopt!` macro now go through `deriving(Decodable)` instead.

auto merge of #712 : alexcrichton/cargo/issue-633, r=brson

As pointed in #633, it's currently not possible for a package to reexport the
feature of another package due to the limitations of how features are defined.

This commit adds support for this ability by allowing features of the form
`foo/bar` in the `features` section of the manifest. This form indicates that
the dependency `foo` should have its `bar` feature enabled. Additionally, it is
not required that `foo` is an optional dependency.

This does not allow features of the form `foo/bar` in a `[dependencies]`
features section as dependencies shouldn't be enabling features for other
dependencies.

At the same time, this passes through features to build commands to solve a few more issues.

Closes #97
Closes #601 (this is an equivalent solution for that problem)
Closes #633
Closes #674

auto merge of #719 : alexcrichton/cargo/update-docopt, r=alexcrichton

Update to rust master to remove libdebug

Ignore EPERM when scanning for packages

We won't make much progress reporting the error back up the chain, so we may as
well carry on!

Pass features to native build commands

Closes #97
Closes #601 (this is an equivalent solution for that problem)

Allow reexporting of features between packages

As pointed in #633, it's currently not possible for a package to reexport the
feature of another package due to the limitations of how features are defined.

This commit adds support for this ability by allowing features of the form
`foo/bar` in the `features` section of the manifest. This form indicates that
the dependency `foo` should have its `bar` feature enabled. Additionally, it is
not required that `foo` is an optional dependency.

This does not allow features of the form `foo/bar` in a `[dependencies]`
features section as dependencies shouldn't be enabling features for other
dependencies.

Closes #633
Closes #674

Require `make` is run before `make install`

I can't quite remember why this ifdef is present to silently run `make` as a
normal user, and it doesn't seem to work if `make install` is run while as root,
so I'm just removing it and requiring that `make` is run before `make install`
unconditionally.

Closes #708

auto merge of #709 : alexcrichton/cargo/issue-705, r=brson

This will enable passing `-C rpath` on all compiles to rustc itself.

Closes #705

Add an `rpath` option to the profile section

This will enable passing `-C rpath` on all compiles to rustc itself.

Closes #705

auto merge of #700 : alexcrichton/cargo/issue-697, r=brson

When a source has multiple crates inside of it, `cargo update -p foo` would
previously not actually update anything because the extra crates were continuing
to lock the source to the same revision. This change updates the "avoid me"
logic to avoid *sources*, not *packages*.

Closes #697

auto merge of #699 : alexcrichton/cargo/issue-695, r=brson

Closes #695

auto merge of #706 : kballard/cargo/patch-1, r=alexcrichton

`$(OUT_DIR)` may contain spaces, so it needs to be quoted. It also needs to be expanded by the shell, not by `make`, or any quotes/backslashes in the value will cause problems.

Tweak native-build.md example

`$(OUT_DIR)` may contain spaces, so it needs to be quoted. It also needs to be expanded by the shell, not by `make`, or any quotes/backslashes in the value will cause problems.

auto merge of #698 : eagleflo/cargo/new-invalid-characters, r=alexcrichton

Crate names have tight restrictions in Rust. `cargo new` should not allow invalid characters in crate names, as such crates will just fail to compile later on.

This check is based on the one found in rustc's `validate_crate_name` (https://github.com/rust-lang/rust/blob/master/src/librustc/metadata/creader.rs#L185-L189).

auto merge of #703 : alexcrichton/cargo/doc.crates.io, r=alexcrichton

The actual crates.io domain will become the registry itself, but the
auto-generated documentation from this repository will continue to be available
at the doc.crates.io domain.

In the meantime, we've set up redirects from crates.io and www.crates.io to
doc.crates.io and the github-pages site will now be doc.crates.io